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Course  Objectives 


The  course  will  focus  on  : 

•  Using  the  Software  Process  Management  System 

•  Learning  to  create  process  models 

•  Learning  how  each  element  of  the  SPMS  interacts 
with  other  elements 

•  Learning  how  to  use  the  project  specific  plans 
to  assist  in  validation  of  the  process  models 


By  the  end  of  the  course  ,  students  will  have: 

•  Become  familiar  with  the  elements  of  the  SPMS 

•  Created,  instantiated,  and  simulated  their  own 
process  models 


Course  Schedule 


Day  1 

9:00  Course  Introduction  and  Overview 
SPMS  Overview 

Process  Models  vs  Project  Plans 
Granularity  Issues 
Nodes,  Constraints,  Phases 
Architectural  Levels 
Development  Modes 
Hierarchical  Models 
Measurement  Model 
Graphical  Representation 
1 0:00  Building  a  simple  Model  in  Xpert 
Exercise  1 

10:30  SPMS  model  representation 
Exercise  2 

1 1 :00  Project  Specific  Data 
1 1 :30  Exercise  3 
1 2:00  Lunch 

1 :00  Discussion  of  exercises 

1:30  Scheduling  the  Plan 

2:00  Exercise  4 

2:30  Graphic  Monitoring 

3:00  Simulation  of  the  Plan 

3:30  Exercise  5 

4:00  Discussion  and  review 

Day  2 

9:00  Review/Questions 

9:30  Validation  tasks  and  Rework 

1 0:00  More  Complex  Models 

1 0:30  Exercise  6 

1 1 :00  Discussion  &  Questions 

1 1 :30  Summary  and  support  issues. 


Process  Capability  Improvement  Focus 


in 
c  « 

°  s 

*■*  o 
c  L_ 
a>  a. 

a,  tf)  a» 

l.  3  e 

Q.  §  g 
c  > 
0—0 
o  L 
w  C  Cl 

a>  o  c 

Q  O  £ 


in 

tn 

o 

o 

o 

ir 

a.  m 


a>  £ 

c.  *i  — 
iu  E  w 

_ o>  *n  i_ 

^  t.  »  *' 

to  3  ^ 

§  ?S® 

2n«« 
S>to  *S  > 

—  a> 

OC  I  £E 


o> 

c 


Software  Technology  Center 


What  is  Software  Process  Management? 


Support,  Guide, 
Check,  &  Enforce 
Development 
Activities 


Process  Models  vs  Instantiated  Plans 


Process  Model: 

Represents  a  prototypical  sequence  of  tasks, 
milestones,  constraints,  and  products  necessary  to 
produce  a  prototypical  single  instance  of  each  of  the 
types  of  software  component  within  the  process 
model. 

Process  models  provide  the  framework  for  producing 
plans  that  may  be  replicated  and  a  framework  for 
metrics  which  may  measure  the  process. 

Plans: 

Contain  numerous  specific  named  and  inter-related 
instances  of  the  software  components  and  the 
tasks  necessary  to  produce  them  according  to  the 
process  model. 

Plans  are  the  baselines  for  monitoring  progress  of 
a  specific  software  development  project. 


Model  +  Project  Data  =  Plan 


Products, 

Monitoring  methods, 

and  tables  to  hold  collected  metric  information. 


Architecture  of  SPMS 


Process  Model  Granularity  Issues 


•  Entire  model 

-  Import  Graphic  Model 

-  Delete  Model 

•  Named  Groups  of  Components 

-  Edit  Model 

•  Individual  Components 

-  Edit  Process 

-  Edit  Product 

-  Edit  Constraints 

-  Edit  10  and  Constraints 


Nodes 


•  Task: 

The  basic  component  of  a  process  model. 


/ - \ 

s. _ J 


•  Milestone: 

A  special  node  used  to  highlight  important 
events  in  a  process  model. 


•  Interface: 


(CZD) 


A  special  node  used  to  link  subnetworks 
in  the  process  model.  Represents  a 
product  in  the  SPMS. 


•  Reverse:  (  OR  ) 


A  special  node  used  which  allows  the 
successor  to  start  when  any  predecessor  is 
complete  rather  than  when  allp redecessors 
are  complete. 


Constraints 


•  Finish  to  Start: 

-  Specifies  that  a  task  cannot  start  until  its  predecessor  is  complete. 

•  Finish  to  Finish: 


-  Specifies  that  the  completion  of  a  task  dictates  the  completion  of  its 
successor.  May  have  a  duration  to  specify  lag  time  between  a  task  and 
its  successor. 


•  Start  to  Finish: 


-  Specifies  that  a  task  cannot  finish  until  its  predecessor  starts. 

•  Start  to  Start: 

-  Specifies  that  two  tasks  can  start  together.  A  duration  applied  to  this 
type  of  constraint  indicates  a  lead  time  between  the  start  of  one  task 
and  the  start  of  its  predecessor. 

•  Hammock  links: 

-  May  have  resources 

-  Dynamic  durations  calculated  as  elapsed  time  between  end  points. 

-  Used  to  represent  phases  in  SPMS 


Architectural  Levels 


•  Alternative  architectural  levels  within  a  process  model 

•  Nodes  in  a  process  model  contain  an  architectural  level  parameter. 

•  Project  specific  software  components  also  contain  this  parameter. 

•  Plans  contain  nodes  in  which  the  model  and  component  parameters 
match  on  both  architectural  level  and  development  mode. 


Development  Modes 


•  Develop  module? 

•  Reuse  module? 

•  Prototype  module? 

•  User  defined.... 


•  Alternative  sequences  of  nodes  within  a  process  model 

^  •  Nodes  in  a  process  model  contain  a  development  mode 
parameter. 

•  Project  specific  software  components  also  contain  this 
parameter. 

•  Plans  contain  nodes  in  which  the  model  and  component 
parameters  match  on  both  architectural  level  and 
development  mode. 

•  Allows  instantiation  time  tailoring  of  model. 


Hierarchical  Models 


Some  Possibilities: 

Process  component  "A"  might  be  at  the  SYSTEM  level. 
Process  component  "B"  might  be  at  the  CSCI  level. 

"B"  might  be  considered  "Part  of"  "A" 

Process  components  "A"  and  "B"  might  be  at  the  same 
level  and  "B"  specify  greater  detail  than  other  portions 
of  "A".  "B"  might  be  considered  "Part  of"  "A" 


How  do  you  want  to  view  parts  in  the  model  editor? 


Executable  Process  Models  and  Metrics 
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Both  metrics  and  process  models  are  integral  to  SPMS's 


RADC  Quality  Framework 
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TABLE  1.1-3  SOFTWARE  QUALITY  FRAMEWORK 
FACTORS  AND  ASSOCIATED  CRITERIA 


ACCURACY 

ANOMALY  MANAGEMENT 
AUTONOMY 

DISTRIBUTEDNESS  ; 

EFFECTIVENESS  -  COMMUNICATION  X 

EFFECTIVENESS  -  PROCESSING  X 

EFFECTIVENESS  -  STORAGE  X 

OPERABILITY 

RECONFIGURABILITY 

SYSTEM  ACCESSIBILITY 

TRAINING _ 

COMPLETENESS 

CONSISTENCY 

TRACEABILITY 

VISIBILITY  _  , _ 

APPLICATION  INDEPENDENCE 

AUGMENT AB ILITY 

COMMONALITY 

DOCUMENT  ACCESSIBILITY 

FUNCTIONAL  OVERLAP  ! 

FUNCTIONAL  SCOPE 

GENERALITY 

INDEPENDENCE 

SYSTEM  CLARITY 

SYSTEM  COMPATIBILITY 

VIRTUALITY _ 

MODULARITY 

SELF-DESCRIPTTVHNESS 

SIMPLICITY 


xxxx 


Data  Collection  Forms 
by  Phase  and  Architectural  Level 


Software  Development  Phase 


Form 


Appendix  A.  Metric  Scoring  Formulas  Based  on  Metric  Elements 
by  Architecture  Level  and  Phase 


Validation  Tasks  and  Rework  Node  Id'S 


Task  "A" 
Process  id 
123 


Task  "B"  Milestone  Product 

DCF  A,  123  "C"  "D" 

SYSTEM 


Task  "B"  is  a  validation  task. 


When  Task  "B"  begins  it  requests  that  the  Data  Collection  Form  (DCF  A)  associated 
with  it  be  filled  with  data. 

When  the  data  becomes  available,  the  metrics  associated  with  this  project  are 
computed  and  compared  with  the  quality  goals  of  Product  "D". 

•  Quality  goals  met,  then  Task  "B"  is  complete  and  the  Milestone  "C"  is  met  and 
Product  "D"  becomes  available. 


•  Quality  goals  not  met  then  replanning  will  find  the  task  associated  with  product 
"D"  which  is  of  the  process  type  "123"  and  use  it  as  the  starting  point  for  cloning 
up  to  and  including  the  validation  task. 


Task  "A”  Task  "B" 

Process  id  DCF  A 

123  SYSTEM 


Impact  of  Re-Work  on  other  Process  Components 

T asks  Not  Started  Case 


Process  Component  1 


1 

9 

-f 3 , 

c. 

Task  "A" 
Process  id 
123 

Product  "E" 

Version  1.0 

-f 

Task  "B" 
DCF  A, 
123 

SYSTEM 

/  Milestone 
/  "C" 

/ 

Product 

"D" 

6 

7 

8 

u - V 

Task  "A" 
Process  id 
123 

Product  "E" 

Version  2.0 

Task  "B" 
DCF  A 
SYSTEM 

Impact  of  Re-Work  on  other  Process  Components 

Tasks  In  Progress  Case 


Process  Component  1 


Process  Component  2 


Impact  of  Re-Work  on  other  Process  Components 

Tasks  Complete  Case 


Task  "A" 
Process  id 
123 


Task  "A" 
Process  id 
123 


Product  "E" 
Version  1.0 


Product  "E" 
Version  2.0 


Process  Component  1 


Task  "B" 
DCF  A, 
123 

SYSTEM 


Task  "B" 
DCF  A 
SYSTEM 


Milestone  Product 
C 


Process  Component  2 


Product  "E" 
Version  1.0 


Task  "G" 
Finished 


Task  "H" 
Finished 


Product  "E" 
Version  2.0 


Task  "G" 


Task  "H" 


Exercise  1 


1 .  Using  the  associated  hand-out  input  the  System  Requirements  Analysis 
subset  of  the  process  model  as  a  part  of  a  larger  model. 

2.  Create  a  Systems  Analysis  Phase  . 

3.  Use  only  Finish-to-Start  constraints. 

4.  Export  the  model  from  Xpert. 


6.  DEVELOPMENT  PROCESS 


€.0.1  The  developer  shall  implement  a  process  for  developing  the 
softvare.  The  development  process  vill  be  composed  of  the  following 
major  activities x  . 

a.  System  Requirements  Analysis 
:  .  2>.  System  Design 

c.  Softvare  Requirements  Analysis 

d.  Softvare  Architectural  Design 

e.  Softvare  Detailed  Design 

f.  Softvare  Coding  and  Testing 

g.  Softvare  Integration  and  Testing 

h.  Softvare  Configuration  Item  Testing 

i.  System  Integration  and  Testing 

j.  System  Testing 

X.  System  Installation  and  Checkout. 

6.0.2  The  developer  shall  select  and  map  these  activities  onto  the 
life  cycle  model  established  for  the  softvare  project.  The  selected 
activities  may  overlap  and  may  be  performed  iteratively  or 
recursively. 

6.0.3  The  developer  shall  use  the  methodologies,  standards,  and 
procedures  that  are  systematic,  adequately  documented,  and  established 
by  the  developer's  organization  for  performing  the  activities. 

6.0.4  The  developer  shall  use  the  computer  programming  language (s) 
as  specified  in  the  contract  to  code  the  deliverable  softvare. 

6.0.5  The  developer  shall  consider  incorporating  non-developmental 
items  into  the  deliverable  softvare.  Incorporation  of  such  items 
shall  comply  with  the  documentation,  data  rights,  warranty,  and  other 
requirements  as  specified  in  the  contract. 

6.0.6  The  developer  may  employ  non-deliverable  items  in  the 
development  or  maintenance  of  softvare.  However,  the  developer  shall 
ensure  that  the  operation  and  maintenance  of  softvare  after  its 
delivery  to  the  purchaser  vill  be  independent  of  such  non-deliverable 
items.  In  case  such  independence  cannot  be  ensured,  the  developer 
shall  treat  the  non-deliverable  items  as  non-developmental  upon 
notifying  the  purchaser  regarding  the  impact  of  non-deliverable  items 
on  the  cost,  schedule,  operation,  and  maintenance  of  the  deliverable 
softvare. 
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6.1  System  pegulrements  Analysis.  The  developer  shall  perform  or 
support  the  following  system  requirements  analysis  activities. 

6.1.1  Engineering.  The  developer  shall  analyze  the  statement  of 

need,  statement  of  work,  and  recommended  solutions,  if  available,  to 
define  a  set  of  system  requirements  addressing  the  following  as  a 
minimum:  . 

.* 

a.  Functions  and  capabilities  of  the  total  system,  including 
performance,  quality,  and  physical  characteristics  and 
environmental  conditions  under  which  the  system  will  perform; 

b.  Safety  requirements,  including  those  related  to  equipment 
characteristics  and  degradation,  methods  of  operation  and 
maintenance,  environmental . influences,  and  personnel  injury? 

c.  Security  requirements,  including  those  related  to  operational 
and  maintenance  environments  and  compromise  of  sensitive 
information  or  materials; 

d.  Human  engineering  requirements,  including  those  related  to 
constraints  on  personnel,  areas  needing  concentrated  human 
attention  and  sensitive  to  human  errors,  and  training; 

e.  Interfaces  requirements  for  interfaces  external  to  the  system, 
including  interfaces  with  users; 

f.  Operation  and  maintenance  requirements. 

6.1.2  Qualification  Testing.  The  developer  shall  define  a  set  of 
system  qualification  requirements,  including  qualifications  methods, 
for  verification,  validation,  and  testing  of  the  system  requirements. 

6.1.3  Documentation.  The  developer  shall  document  the  system  and 
qualification  requirements  in  a  system  requirements  document  in 
accordance  with  section  9.4. 

6.1.4  Product  Evaluation.  The  developer  shall  perform  evaluations 
of  the  system  and  qualification  requirements  for  the  criteria 
identified  below  as  a  minimum.  When  a  problem  is  detected,  corrective 
actions  shall  be  taken  in  accordance  with  section  9.3.3. 

a.  Consistency  —  external  and  internal; 

b.  Traceability; 

c.  Test  coverage  of  requirements; 

d.  Testability; 

e.  Feasibility  of  design,  operation,  and  maintenance; 

6.1.5  Formal  Fevlew.  The  developer  shall  conduct  one  or  more  system 
requirements  reviews  in  accordance  with  section  9.2. 

6.1.6  Configuration  Management.  The  developer  shall  place  the 
documents  identified  below  under  configuration  management  and  perform 
configuration  control  in  accordance  with  section  9.1: 

a.  Statement  of  work 

b.  System  requirements  document. 
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Exercise  2 


1 .  Import  the  graphic  model  of  Exercise  1  into  the  SPMS. 

2.  Browse  the  fine  grained  components  using  "Edit  Process",  "Edit 
Products",  and  "Edit  Constraints"  buttons. 

3.  Browse  the  product  to  producer  and  consumer  relations  using  the 
"Edit  10  and  Constraints"  button 

4.  Browse  the  hierachical  coarse  grained  components  using  the  "Edit 
Model"  button 


5.  Edit  your  model  as  desired  . 


Exercise  3 


1 .  Move  to  the  Project  Interface  and  create  a  new  Project. 

2.  Define  a  system  level  component  with  a  source  to  match  the 
development  mode  of  your  model. 

3.  Create  a  Plan  by  selecting  your  model  and  your  project  and  providing  a 
name  for  your  plan. 

4.  Export  the  plan  from  the  SPMS 


Exercise  4 


1 .  Create  a  new  project  in  XPERT.  Clear  the  New  Subproject  which  is 
automatically  created.  From  the  Date  Control  Panel,  Turn  off  the  Show 
Hours/Minutes  option . 

2.  Import  your  plan  into  XPERT. 

3.  Use  "Clean  Up"  to  improve  the  readability  of  the  activity  network. 

4.  Select  the  tasks  in  the  network  and  enter  durations.  (Format  is 
"weeks, days". 

5.  Perform  Time  Analysis. 

6.  Build  a  Gannt  chart  to  display  your  results.  See  Gannt  chart  options  for 
tailoring  the  chart. 

7.  Build  a  Table  view.  Use  "Selected  Table"  with  "0"  resources  displayed 

8.  Select  the  entire  table  and  Export  it  from  XPERT,  (use  name.DAT" 
format) 


Exercise  5 

1 .  Import  the  scheduled  plan  into  the  SPMS. 

2.  Randomize  the  durations  of  your  plan. 

3.  Create  some  graphs  for  monitoring  your  plan  during  execution 

4.  Execute  the  plan. 


Exercise  6 


1 .  Open  your  model  in  Xpert. 

2.  Add  a  validation  task  for  the  Systems  Requirements  Document. 

3.  Be  sure  your  DCF  and  rework  node  id  are  appropriate! 

4.  Alter  the  constraints  to  allow  some  tasks  to  begin  when  any  of  their 
inputs  are  available  but  only  finish  when  all  of  their  required  inputs  have 
been  made  available. 

5.  Export  the  model  from  Xpert. 

6.  Import  the  model  into  SPMS 

7.  Create  a  new  project. 

8.  Select  measures  and  default  quality  goals  for  this  project. 

9.  Define  Parts. 

1 0.  Create  a  new  plan  using  your  new  model  and  new  project. 

1 1 .  Execute  the  plan. 

1 2.  Replan  as  necessary. 


